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This invention relates to the Internet, more particularly to methods 
and apparatus for producing and using portals and portlets in web 
applications to provide enhanced capabilities for web sites. 

0 Background of the Invention 

The World Wide Web brought a major paradigm shift to communications 
over the Internet, • conveying graphical information to users. With the 
advent of the Web there was and still is demand for increasing 

The Portal (previously known as a web portal) has brought a paradigm 
shift in internet space. A web site that offers an array of resources or 
services such as email, forums, search engines, databases or other 

:0 information may be considered to be a portal. The first web portals may 

have been online services. For the first time, users surfing the 
internet were able to see web pages that were assembled with and offered 
information coming from various sites in the world wide web, yet the 
aggregation's constitution was transparent to the user. A user making use 

:5 of a typical web browser sees a cohesive web page displayed. The 

origination of different parts of the page from various internet sites not 
associated with the web site being viewed is not readily apparent. These 
parts are termed Portlets. 

;0 Portlets are the visible active com ponents encf^users see within 

their portal pages. Similar to a window in a PC desktop, each portlet 
*owns ff a portion of the browser or Personal Digital Appliance screen where 
it displays results. 

;5 From a user's view, a portlet is a content channel or application to 

which a user subscribes, adds to their personal portal page, and 
configures to show personalized content. 



From content providers' view, a portlet is a means to make available 
their content. 
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From a portal administrator's view, a portlet is a content container 
tliat can be registered with the portal, so that users may subscribe to it. 

From a portal's point of view, a portlet is a component rendered 
> into one of its pages. 

From a technical point of view, a portlet is a piece of code or a 
small application that runs on a portal server and provides content that 
is to be embedded into portal pages. In the simplest terms, a portlet may 
) be a Java™ servlet that operates inside a portal. 

Each part (portlet) of a given page (typically sourced from 
different places in the world wide web) can collaborate with another part 
(portlet) of the same page to achieve higher function for a user surfing 

5 or accessing the page. Thus, a portal becomes t he single poi nt of access 

for multiple users, via multiple channels, to multiple sources o£ - - - - — 
information . 

Portals can be applied in various business models, namely: business 
0 to consumer, business to business, or business to enterprise. The key to 

quick adoption of the portal paradigm ties strongly to its ability to. 
integrate existing web application data into the portal framework in a 
seamless fashion. 

5 However, various technical hurdles still exist for such seamless web 

application integration into portal. 

There are limitations in the prior art concerning how the following 
portal artifacts work together with existing web applications. The 
0 implementation of integration of web applications into portal architecture 



Original http request to a portal; 

A http request from the portal to the pertinent web application. 

When different users access a portal page, the original http request 
for each user is directed towards the portal server (a) . The original http 
session for each user is also entirely "owned" by the portal server. Each 
of the portlets has its own independent session called a portlet session. 
When a portlet needs to render information that comes from a given web 
application, (b) , there are typically the following technical hurdles:. 
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i. There is no existing mechanism for a portlet to generate http 
requests and responses to and from the backend web 
application. 

j. There is no existing mechanism to manage multiple requests and 
responses to* a calling portlet (and the portlet session) 
mapping correctly with multiple requests and responses to a 
backend web application (and the web application's session). 
Each (both portlet and web application) maintains its user 
session accordingly. 

This gets complicated when multiple portlets call the same web 
application, with the web application treating these multiple portlets 
requests within the same web application session. 

k. There is no existing mech anism to relay session information 

" between" th^ 

application's session. 

When a well defined set of portlets within the same portlet 
application interact with the one web application at the backend, all the 
participating portlets must be able to retrieve and forward the correct 
session information to the web application at the backend such that the 
information rendered from the web application is consistent with the 
setting of that of the portal of the portlets. Examples of such setting 
includes locale information, user agent of that particular access etc. For 
example, the responses sent from the web application must be using the 
same locale with the portlet in the portal server who displays it. 

There is no existing mechanism for single sign on such that the 
_j>ortal user's credentia l s will not b e , C ^ l ^^^, f d by k aCkend * **** 

in the user's credentials being challenged when the user moves from one 
part of a web page to a different part of the same web page; as the 



There is no existing mechanism for synchronization of multiple 
requests or responses between portlets of a given portlet application and 
the pertinent web application backend. 

The prior art has limitations concerning how multiple portlets 
---- the same portlet application can collaborate with one another 
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(sharing the same context) as well as with the various integrated web 
applications dynamically is not defined. 

One Usage Scenario involving multiple portlets collaborating by 
sharing the same % context' dynamically will serve to conceptually 
illustrate the limitation: 

With three portlets being displayed on the same portal web page: 

- one portlet shows the account summary by displaying a list of 
accounts 

- the second portlet shows a given account's list of outstanding 
invoices 

- the third portlet shows a given account's order history summary 



The second and the third portlets aire" cbntextually bound^to the 
first portlet dynamically, reflecting outstanding invoices (2 nd portlet) 
and order history (3 rd portlet) and are synchronized with an account 
selected from the account list of the first portlet. 

Limitations of the prior art: 

i. No mechanism exists to define a sub-grouping of portlets within a 
portlet application that would work collaboratively. 

5 

j. No mechanism exists to define a context (that can be dynamically 
changed) shared among this sub-group of portlets within a given 
portlet application: example of context here is the selected account 
in portlet 1, such account selection can be changed dynamically. 

example of the change of selection from one account to another 
account from the account list in portlet 1 of the above example. 



J5 
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1. No mechanism exists to register a predefined action (or responses) 
for each participating portlets within the sub-group of portlets 
that share the same context: example of displaying the list of 
outstanding invoices (action in portlet 2) when the context is 
changed (from one account selection to another in portlet 1) . 

m. No mechanism exists to relay that dynamic context to the relevant 
integrated web applications 
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There is no mechanism existing in the prior art to define a refresh 
sequence for a group of portlets within a portlet application 

i. There is no provision today for a portal designer to specify the 
refresh order of a given set of portlets being displayed. 

In our scenario above, the portal designer would want to have the 
first portlet (account list) refreshed first, the second portlet 
refreshed second etc. so that the 2 n * and the 3 rd portlets 
automatically have. Defined actions (when the portlet is deployed) 
taking place in a correct sequence. 

There is a lack of a well defined mechanism in portal architecture' 
to support the aggregation of portlets based on business rule and user 
_profiling_informatiojoj : ncluding the users • role. 



i. There is no existing mechanism to define aggregation of portal 
resources per user based on business rules. 

Example: all teenage portal users see one group of portlets, all 
senior portal users see another group of portlets. 

j . There is no existing mechanism for such rule based and user based 
aggregation of portlets that is performed dynamically at runtime. 

There is no sharing of portal level business rules and user profile 
information with pertinent integrated back end web applications. 

There is no sharing of business rules or user segmentation 
information with an integrated web application such that these rules and 



backend web application. For example, if there is a rule defining the age 
range of a teenager, such a rule should be visible and applicable to the 



55 



Termino 1 ogy 
Portlets 



40 



Portlets are the visible active components that the end users see 
within their portal web pages. Similar to a window in a PC desktop, each 
portlet "owns" a portion of the browser or PDA (Personal Digital 
Appliance) screen where it displays portlet specific information. 
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Portlet application 



Port lets can also be grouped together in a portlet application. 
Portlet applications are distributed and deployed using Web archive files 
(WAR) . There are portlet specific extensions to the standard Web 
application deployment descriptor. 

Portlet Messages 

Portlet messages are used for the communication between two portlets 
using portlet actions and portlet messages. The sending portlet creates a 
portlet action, encodes the action into a URL. When the URL is addressed, 
e.g. by a user trying to accomplish an task, the action listener is called 
and sends a portlet message to send the necessary data. 

Portlet Session 

A Portlet session is created for each portlet instance for each user 
logging on to maintain session information for each user per portlet 
instance. 

Portlets of a given portlet application have limitations today 
concerning how multiple portlets within the same portlet application can 
collaborate with one another, sharing the same context, such these 
portlets that render responses from the integrated web application are 
able to render content dynamically related to the context in effect. 

There is also no mechanism today to define subgroup of portlets 
within a given portlet application to work collaboratively in such a 



There is also 



. no mechanism to detect the change m context dynamically 



is there mechanism today to register a predefined action for the 
participating portlets, including mechanism to relay that dynamic context 
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Summary of the Invention 

The various embodiments and aspects of the invention herein address 
one or more shortcomings of the prior art. 

A method according to the invention makes use of a dynamic context 
Portlet group that enables the collaboration among portlets within the 
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same dynamic context portlet group to achieve business process and 
information integration and synchronization. 

Another embodiment of the invention provides means for managing the 
multiple associated portlets; each associated portlet having a portlet 
descriptor describing context names, with defining context values. Each 
group of portlets includes a master portlet and at least one slave 
portlet; each group of portlets share context names in common. 

Another embodiment of the invention includes means in the portal 
server for broadcasting communicating changes in context values of a 
master portlet to slave portlets. Each portlet descriptor includes refresh 
priority description of the portlet. The master portlets have higher 
priorities than slave portlets. 

"Embodiments " of" this invent ion make possible the" synchronization of " - 
information integration and business process integration. Simple 
structure of dynamic context group enables the contextual grouping through 
deployment without requiring implementation change of the portlets, 
providing advantage of the invention. 

One embodiment of the invention provides apparatus for displaying to 
a user a web portal for a web application, the web portal displaying a 
plurality of associated portlets, sharing information with each other, 
accessible by the user; including: a portal server for operating a web 
portal to provide access to the web application; a portlet application for 
operating on the portal server, for managing a collection of associated 
portlets; the portlet application includes: means to initiate portlets on 
requests of a user to access the web application; means to manage a 
portlet ^S^iSSn^ SLMS^h^ ob 3 ect for the portlets; and, a portlet 
^%HcM 

application session object for saving parameters from user requests for. 
associating the portlets with the with the portlet application session 



to 



The apparatus of the invention may include a portlet application- 
communication client in the" portlet application for communicating between 
the portlet application session object and the web application to convey 
user requests received from the associated portlets to the web 
application. The portlet application may assign a common key to each 
portlet associated with a portlet application session object. 
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Another embodiment of the invention provides an apparatus for 
displaying a web portal for a web. application to a plurality of users, 
the web portal displaying a plurality of portlets, sharing information, 
accessible by the users; including: a portal server for operating a web 

5 portal to provide access to the web application; a portlet application for 

operating on the portal server for each of the plurality of users, for 
managing a collection of associated portlets for each of the plurality of 
users; each the portlet application includes: means to initiate portlets 
on requests of one of the plurality of users to access the web 

D application; means to manage a portlet application session object for the 

portlets; and, a portlet application session object data store controlled 
by the portlet application session object for saving parameters from user 
requests for associating the portlets with the with the portlet 
application session object. 



Another " eitobdiment o'r 
displaying to a user a web portal for a plurality of web applications, the 
web portal displaying a plurality of associated portlets, sharing 
information with each other, accessible by the user; including: a portal 
0 server for operating a web portal to provide access to the web 

application; a plurality of portlet applications relating respectively to 
the plurality of web applications for operating on the portal server, each 
portlet application being adapted to managing a collection of associated 
portlets; each the portlet application includes: means to initiate 
5 portlets on requests of a user to access one of the plurality of web 

application; means to manage a portlet application session object for the 
portlets; and, a portlet application session object data store controlled 
by the portlet application session object for saving parameters from user 
requests for associating the portlets of the portlet application with the 

,0 with the portlet application session object of the portlet application 

session. 

Another aspect of the apparatus of the invention includes a user 
^^4,^ ™* a g gj^ ations , 



\$. with the portlet application session object. 

Still another embodiment of the invention provides apparatus for 
displaying to a user a web portal for a web application, the web portal 
displaying a plurality of associated portlets, sharing information with 
10 each other, accessible by the user; including: a portal server for 

operating a web portal to provide access to the web application; a portlet 
application for operating on the portal server, for managing a collection 
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of associated port lets; the portlet application including: means to 
initiate a first portlet on request of a user to access the web 
application; means to create a portlet application session object for the 
user for the first portlet; means to save parameters from the request; 

5 means to generate additional portlets associated with the first portlet 

on further requests of the user to access the web application; a portlet 
application session object data store controlled by the portlet 
application session object for using the saved parameters for associating 
the additional portlets with the with the portlet application session 

0 object; and, means to create a portlet application communication client 

(httpClient) for communicating with the portlet application session object 
and the web application to convey user requests received from the first 
and additional portlets to the web application. 

5 The apparatus may include a portlet application communication client 

iii the portlet: application . for" communicating "between tne portlet- — 
application session object and the web application to convey user requests 
received from the associated portlets to the web application. 



10 



The portlet application preferably assigns a common key to each 
portlet associated with a portlet application session object. 



A user session information table adapted to connect to multiple web 
applications with the portlet application session object may 
>5 advantageously be provided. 

Another embodiment of the invention provides apparatus for 
displaying to a user a web portal for a web application, the web portal 
displaying a plurality of associated portlets, sharing information with 
SO each other, accessible by the user; including: a portal server operating a 



operating on the portal server, for managing a collection of associated 
portlets; the portlet application including: means to initiate portlets on 
^^fi..,g^M^X %^^^^^^^^^^X^Xm^^m^, t o manage a n ^ _ 



pert let application session object for the portlets; and, a portlet 
^plication session object data store controlled by the portlet 
application session object for saving parameters from user requests for 
associating the portlets with the with the portlet application session 
ob j ect . 

tether aspect of the invention provides a method of sharing 
Ir.f crr^tion between a plurality of associated portlets in a web portal 
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including: granting access for each of the plurality of associated 
portlets to a portlet data store; permitting each of the plurality of 
associated portlets to write data to the portlet data store and to read 
stored data from the portlet data store. 

The method above may advantageously provide a system wherein the 
associated portlets are managed by a portlet application adapted to 
operate on a data processing system; wherein the portlet data store 
comprises portlet application storage managed by a portlet application 
session object which controls reading and writing of data by the 
associated portlets in the data store permitting exchange of data among 
the associated portlets of the portlet application. 

Another aspect of the invention provides apparatus for sharing 
information ^between multiple associated portl ets in a web po rtal 

* • ~~ n .1 j • _T " ~ 1 Vv^T -i ^-»4- -i />n f rt-r twa-nan"? n rr " "Irh ft mill fcir>le aSSOClc 



including: a portlet application for managing the multiple associated 
portlets; a portlet application data store; means for granting read/write 
access to the data store by the multiple associate portlets to enable the 
portlets to exchange data among each other. 

:0 

Yet another aspect of the invention provides a portlet (application) 
server capable of operating on a portal server for hosting multiple 
associated portlets in a web portal including: means for managing the 
multiple associated portlets; means for managing a portlet application 
>5 session object; a portlet application data store managed by the portlet 

application session object for granting read/write access to the data 
store to the multiple associate portlets to enable the associated portlets 
to exchange data among each other. 



jn An other aspect of t he in vention provides a portlet (application) 

Hserve^^ 



associated portlets in a web portal including: means for managing the 
multiple associated portlets; means for creating and managing a portlet 



35 managed by the portlet application session object for granting read/write 

access to the data store to the multiple associate portlets to enable the 
associated portlets to exchange data among each other. 



Advantageously, the portlet application assigns a common key to each 
40 portlet associated with a portlet application session object. 
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Another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
portlets in a web portal accessible by a user, including: portlet 
application means for managing the multiple associated portlets; portlet 
application means for managing a portlet application session object for 
the user; portlet application means for granting the key to each 
associated portlet for controlling access to the portlet application 
object. 

Still another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
portlets in a web portal accessible by a user, including: portlet 
application means for managing the multiple associated portlets; portlet 
application means for creating and managing a portlet application session 
object .for., the user: portlet, application jaeans for creat in g and manag ing a 



key for the user for the portlet application" ses^ 
application means for granting the key to each associated portlet for 
controlling access to the portlet application object. 

Advantageously one portlet application is assigned to each user and 
one key is assigned respectively for each user to respective portlet 
application objects for each portlet application. 

Another aspect of the invention provides apparatus for displaying to 
a user a web portal for a web application including: a portal server for 
operating a web portal to provide access to the web application by a user; 
a portlet application, for managing a collection of associated portlets, 
for operating on the portal server; a portlet application session object 
for the user for the associated portlets; a portlet application session 

j ^j dSSLm ^Sk^ m SSS^ mSn ^^m i ^ m u fcX n m frfP i P m rt f application ses si on Q^j g^ f ^ 

""pcrtTe^ 

data store for communicating between the associated portlets and the web 
application to convey user requests received from the associated portlets 



for storing and synchronizing requests from the associated portlets to 
enable the communication client to generate synchronized to the web 
application. 

Preferably the portlet application communication client is adapted 
to send information including requests over a network to a web application 
end receive information including responses to the requests from the web 
application. 
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Another aspect of the invention provides apparatus for displaying to 
a user a web portal for a web application including: a portal server for 
operating a web portal to provide access to the web application by a user; 
a portlet application, for managing a collection of associated portlets, 

> for operating on the portal server; a portlet application session object 

for the user for the associated portlets; a portlet application session 
object data store controlled by the portlet application session object; a 
portlet application communication client linked to the portlet application 
data store for communicating between the associated portlets and the web 

3 application to convey user revests received from the associated portlets 

to the web application; the communication client having a request buffer 
for storing and serializing requests from the associated portlets to 
enable the communication client to generate serialized to the web 
application . 

Preferably/ the portlet application communi'catron -clxent™xs -adapt ett 
to send information including requests over a network to a web application 
or web application server and receive information including responses to 
the requests from the web application. 

0 

Another aspect of the invention for a portal server adapted to 
operate a web portal to provide access to a web application; having a 
portlet application operating on the portal server, for managing a 
collection of associated portlets; wherein the portlet application 
5 includes: means to initiate portlets on requests of a user to access the 

web application; means to manage a portlet application session object for 
the portlets; and, a portlet application session object data store 
controlled by the portlet application session object for saving parameters 
from user requests for associating the portlets with the with the portlet 
application session object, the appa ratus including: a portlet application 



store for communicating between the associated portlets and the web 
application to convey user requests received from the associated portlets 



;5 having a user session information store (mapping table) for storing user 

session information including selected information from the set of the 
following user session information: user id, user credentials, language 
preferences, session timeout information, session id, etc. for mapping the 
user session information to a corresponding session of the web 

10 application . 
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The session timeout information preferably includes session timeout 
information of the portal server and the web application. 

Another aspect of the invention provides port let application, for 
managing a collection of associated portlets in a portal, for operating on 
a server providing access to a web application by a user; the associated 
portlets having portlet request parameter maps storing data and 
instructions from user requests to the portlets; a portlet application 
session object for the user for the associated portlets; a portlet 
application session data store controlled by the portlet application 
session object; a portlet application communication client (httpClient) 
linked to the portlet application data store for communicating between the 
associated portlets and the web application to convey user requests 
received from the associated portlets to the web application; the 
communication clie nt ha ving a request buffer for storing req uests from 
"portlet request parameter maps of the" associated portlets to enable -^ 
communication client to provide data and instructions for the web 
application. 

Another aspect of the invention provides a portlet application 
communication client (httpClient) linked to the portlet application data 
store for communicating between the associated portlets and the web 
application to convey user requests received from the associated portlets 
to the web application; the portlet application communication client 
having a user session information store (mapping table) for storing user 
session information including selected information from the set of the 
following user session information: user id, user credentials, language 
preferences, session timeout information, session id, etc. for mapping the 
user session information to a corresponding session of the web 




Preferably the above includes synchronization means for the portlet 



;5 portal server and the web application by re- authenticating the user if the 

web application times out before the portal server. 

Another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
10 portlets in a web portal accessible by a user, the portal server providing 

messaging means for allowing the associated portlets to message each 
other, including: portlet application means for managing the multiple 



WO 2004/031985 



14 



PCT/GB2003/004238 



associated portlets; each associated portlet having a portlet descriptor 
describing context names; the associated portlets including collaboration 
groups of portlets having corresponding context names defining context 
values; each the group of portlets including a master portlet and at least 
one slave portlet; wherein each the group of portlets share context names 
in common; means in the portal server for broadcasting communicating 
changes in context values of a master portlet to slave portlets of the 
master portlet; means in the portal server for changing context values of 
the slave portlets to match context values of the master portlet as 
broadcast . 

Another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
portlets in a web portal accessible by a user, the portal server having 



managing the multiple associated portlets; each associated portlet having' 
a portlet descriptor; each portlet descriptor including refresh priority 
description for the portlet; the associated portlets including 
collaboration groups of portlets; each the group of portlets including a 
:0 master portlet and at least one slave portlet; means in the portlet 

application means for refreshing the portlets in order of their refresh 
priorities . 

Still another aspect of the invention provides a portlet application 
IS capable of operating on a portal server for hosting multiple associated 

portlets in a web portal accessible by a user, the portal server having 
portlet refresh capability, including: the associated portlets including 
collaboration groups of portlets; portlet application means for managing 
the multiple associated portlets; each associated portlet having a portlet 

description for the portlet, and a refresh description priority for the 
group of portlets of which the portlet is a member; each the group of 
portlets including a master portlet and at least one slave portlet; means 



35 their priorities; means in the portlet application means for refreshing 

the collaborative groups of portlets in order of their group refresh 
priorities . 



40 



The master portlets have higher priorities than slave portlets. 
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Preferably the portlet application refreshes the groups first in 
group priority order and then refreshes within each group in priority 
order . 

5 Another aspect of the invention provides apparatus for displaying to 

a user a web page session for a web application, the web page session 
displaying a plurality of associated collaborative portlets, sharing 
information with each other, accessible by the user including: a portal 
server for operating a web portal to provide access to the web 

.0 application; a portlet application, for managing a collection of 

associated portlets, for operating on the portal server; access means to 
access a rules database; the rules including rules controlling display of 
sets of portlets, pages, page groups to users; selection means to select 
a set of portlets, pages, and page groups to be displayed to a user based 

In another variation of the invention the selection means includes a 
pluggable rules engine, a rules database, and a portlet application 
aggregation engine which applies rules to select and display selected 
20 portlets, pages, and page groups to a user. 

Another aspect of the invention provides apparatus for displaying to 
a user a web page session for a web application, the web page session 
displaying a plurality of associated collaborative portlets, sharing 
25 information with each other, accessible by the user including: a portal 

server for operating a web portal to provide access to the web 
application; a portlet application, for managing a collection of 
associated portlets, for operating on the portal server; roles access 
means to access a roles database; the roles database containing rules 



on user roles ; 

and page groups to be displayed to a user based on an identified role of 
the user. 



Other aspects of the invention provide an article including: a 
computer readable signal bearing medium; computer program code means 
recorded on the medium adapted to perform the methods of the embodiments 
of the invention described above. 

Other aspects of the invention provide an article including: a 
. -r j:cr readable signal bearing medium; computer program code means 
recorojed on the medium adapted to implement the apparatus of any of the 
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embodiments of the invention described above. The medium may be selected 
from the group consisting of magnetic, optical, biological, and atomic 
data storage media as appropriate. 

The medium may be a modulated carrier signal. 

The signal may be a transmission over a network. 



Brief Description of the Dra wings 

3 

Embodiments of the present invention will be described, by way of 
example only, referring to the accompanying drawings in which: 
• Figure 1 depicts a Dynamic Context Chaining Model; 
Figure 2 depicts a Web Application Integration With Portal; 
5 ; , Eigure^^depicts^an^lntegration Strucjtural Diagram; 



Figure 4 depicts an In t egration Flow" DiagramY 
Figure 5 depicts a Structure Diagram for Portal integration with Web 
Application; 

Figure 6 depicts a Flow Chart for Integration; 

Figure 7 depicts an Example Of Dynamic Context Groups for Portlets; 

Figure 8 depicts a Portlet Application Initialization For Dynamic 
Context As Specified In the definition instance; 

Figure 9 depicts a Dynamic Context Portlet Group Run Time Flow; 

Figure 10 depicts a Role Based Dynamic Aggregation Component 
Structure Map; 

Figure 11 depicts a Rule Based Dynamic Aggregation Component Flow 

Map; 

Figure 12 depicts a Role Based Dynamic Aggregation Flow Chart; 
Figure 13 depicts the handling of portlets revests to web 

" BcitnawnTOfiwim^i^ rrt^^jsuiMSS^ ' n*.-,.^*^ ,. .. 

del die 



Figure 14 depicts a sync model diagram; 
Figure 15 depicts a flow chart for a sequence aware portal 
aggregation engine; 



\S and assigning users to the group; 

Figure 17 depicts the assigning a rules database content group 
selection action to a dynamic user group; and, 

Figure 18 depicts the creation of a new action called 
^maleTeenAction" . 
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Detailed Description of Preferred Ember* of the Invention 

A.l. Portal and Web Applications Integration Enablement 

5 Figure 2 illustrates a preferred embodiment of the invention 

illustrating its use with a web portal server. 

A. 1.1 Portlet Application http client 

,0 The portlet (that makes http requests to the back end web 

application) uses the Portlet Application Http client 209 used to open an 
Http connection to a backend web application that runs on a backend 
application server 210. The backend web application retires a Portlet 
Application Http client 209 to provide session support over multiple 

gSgg^n^yge^ue ^ 

All the portlets in the same portlet application use the same portlet 
application Http client object 209 to connect to one or more backend web 
applications. There is one Portlet Application http client 209 per portlet 
application 204. 

JO 

A. 1.2 Portlet Application Session 



The Portlet Application Session object 208 is a unified data store 
object that can be shared by all portlets in a given portlet application. 
>5 This object exists per user and per portlet application. The Portlet 

Application Session object 208 provides infrastructure so that multiple 
portlets in a given portlet application will have independent user 
sessions (called portlet sessions 2 04 205,206) but share the same Portlet 
Application Session, and communicate with the web application on the 

A, 1.3 Portlet application session context 

35 user and per portlet application. This means that all portlets within the 

same portlet application (204, 203) can now have a way to share common 
information among them. 



A.x.4 Session Relay Mechanism 320 

The Session relay mechanism enables the passing of information from 
the criginal http session held by the portal server to the back end http 
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session created by the portlet application's http client. This mechanism 
uses the following infrastructure: 

Cookie Table 305 & Cookie Lookup Key 

Cookie table 305, (a user session information table) is the main 
entity for mapping the portal server cookies to the backend web 
application session cookies • The mapping relationship between the cookie 
of the http requests to the portal server and the cookie of the portlet 
application http client to one given web application is one to one. 
However, A given portlet application http client can make http requests to 
different web applications with each web application maintaining 
independent sessions. With that regard, the mapping between the portal 
server session cookie and that of the backend web applications can be one 

Figure 13 depicts this mapping, in which a number of items are 
illustrated: 

RQ1: cookie from the http request of a user agent (browser) to the 
portal server 

RQA: cookie from the http request of the portlet http application 
client to the web application A 

RQB: cookie from the http request of the portlet http application 
client to the web application B 

The Portlet Application Http client 209 uses this table to look up 
the matching cookie to the backend web application running on the backend 
web application server 210. 

table 305 enables the automatic 



A a - ^ i.u ^^s * ^^ _ 

expiration of a backend web application session when the portal server 



session expires. 



35 



40 



The portlet application http client 209 is created per portlet 
application. The cookie lookup key is stored in the portal application 
session object which is accessible to all the portlets within the same 
portlet application. This cookie lookup key is responsible for matching 
the http session of the portal server with the http session of the back 
end application. 
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The use of the cookie lookup key allows all portlets in a given 
portlet application who share the same Http Client key to retrieve and 
forward the correct set of backend web application information for the 
currently logged in user such that all the portlets in the same portlet 
application work in synchronization to update the backend web application 
being used. The effect is that the end user sees a unified view of the 
backend web application through multiple portlets. 



Portlet Request Parameter Map 



The Portlet Request Parameter Map 308 is in a memory object stored 
in the shared application session data store which is created per portlet, 
per portal server session. It is used to store all request parameters from 
an incoming user request to a particular portlet. 



A. 2 . Dynamic Content Synchronization of Portlets 
A. 2 . 1 Dynamic context Definition template 

Figure 5 illustrates portal integration with a backend web 
application. Reference to Figure 5 will be useful for the following: . 

The Dynamic context Definition template 503 defines the following' 
for each Dynamic Context Group: 

the context and its type (in our previous example, it is the 
Account ID) 

the master portlet who can change the value of the 
context defined 

the slave portlet (s) who get notified when the defined context 
is changed 

notification of the context change 

optionally defines the refresh sequence of the slave portlets 
(master always get refreshed first within a given group) 



One Dynamic Context Definition Template 503 can contain one or many 
Dynamic Context Group (s) . But each Dynamic Context Group can only have 

one master portlet 

one defined context 

one or more than one slave portlets 
Notes: a given portlet can participate in more than one Dynamic 
Context Groups with different roles in each group. 



WO 2004/031985 



20 



PCT/GB2003/004238 



A. 2 .2 Dynamic Context Port lets Grouping Generation Tool 

This tool 501 reads in the Dynamic Context Definition Template 503 
and generates Dynamic Context Master Portlet and Slave Portlets for all 
5 Dynamic Context groups according to the definition specified by updating 

the portlet deployment descriptors 502 correspondingly. 

A. 2. 3 Dynamic Context Group 



.0 A dynamic context group is a subset of portlets that share the same 

context and are grouped under one dynamic context group. A given portlet 
can belong to more than one dynamic context group* 

The Dynamic context group definition document instance 504 is used 

Dynamic Context Master portlet 

Dynamic Context Master Portlet is responsible for 
>0 - detecting the context state change 

notifying all slave portlets on the context state change 



Dynamic Context Slave portlet (s ) 



>5 Dynamic Context Slave portlets do the following: 

pulling for context change as notified by the master portlet 
performs the registered action directed towards the 

corresponding back end application upon notification of 

context change 

Dynamic Context Models 

There are two types of Dynamic Context models that can be used for 



35 

A. 2 . 4 The Sync model 



In the Sync model, depicted in Figure 14, the master portlet 101 
informs the slaves 1701-1703 about the state change of the context of the 
40 Dynamic context master portlet. All slaves will perform actions based on a 

previously defined response to sync up with the master's context state 
change - 
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Sync model diagram 



A. 2. 5 The Chaining model 



5 In the chaining model , indicated in Figure 1, the change of state in 

Master A 101 results in the response action of Slave A 102, Slave A is 
also the Master portlet B, which leads to the change of state in context 
B, resulting in the context change response of Slave B 103, slave B is 
also the master portlet of dynamic context group C, resulting in the 
L0 action response of Slave C. 

A .2. 6 Portlet Transaction Manager: 



A Sequence Aware Portal Aggregation Engine Extension Referring to 

responsible for managing the runtime refresh sequencing of the portlets 
including the creation of portlet requests, responses, and sessions. 

1. The first portlet to be refreshed for any portlet application is 
20 defined as that portlet which is refreshed first among all the portlets 

for a given user. There is no existing mechanism to define the refreshing 
sequence of portlets within a given page. 



Thus, some logic is needed which can identify the master portlet 
25 dynamically at runtime. In the present embodiment a simple scratchboard is 

used where each portlet makes a mark every time it is refreshed, the first 
time a portlet makes a mark on this scratchboard it knows that it is the 
first or master portlet. The next portlet that makes a mark on this list 
can already see that other portlet has made a mark on it and knows that it 

gfeag^^ 



led, the first portlet that makes a double mark on this list becomes 
the master portlet. The master portlet then, reinitializes this list by 
removing the marks of all the other portlets and also one of its double 



;rtiet dynamically every time a request comes in from the portlets' 



porcai server. 



After the first portlet is refreshed the transaction manager takes 
over to refresh the other portlets in the sequence as predefined in the 
—^2 ~ t er and slave portlet mapping of the dynamic context group. 
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2. Sequence sorters The sequence sorter module 1804 is used to sort 
the portlets in their refresh sequence order. It used the portlet 
deployment descriptor to identify the refresh order of each portlet and 
then sorts them out for the request dispatching engine. 

5 

3. Sequence Aware Request Dispatching Engine Extension: This engine 
1805 is used to dispatch requests to the portlets and over-rides the 
portal aggregation engine. Its job is to construct the appropriate portlet 
request and response objects, as well as the portlet session for all the 

0 portlets in the commerce portal application. It is then used by the 

transaction manager to actually refresh the portlets. 

4. Transaction Manager Caching Unit* The transaction manager caching 
unit 1806 is used by the transaction manager 1802 to cache the responses 

engine. This is necessary as when the portal aggregation engine now 
requests for a portlet refresh, these cached responses are sent back to it 
by the transaction manager. This avoids the problem of double refresh per 
incoming portal request. 

0 

A. 3. Rule Based and Role Based Aggregation 

Figure 11 illustrates a rule based dynamic aggregation component 
structure map of a preferred embodiment of this invention. A description 
;5 of the components of the illustrated embodiment and their operation 

follow: 

Portal Resource Translation Module 



translating the set of Portal resources including: portlets, pages and 
page groups into a form that can be parsed and processed by the external 
lies en gine 1022. _____^ 3e ^ 



j 5 Rules Database 



The rules database 1001 holds business manager defined rules for the 
portal aggregation engine 1006. 
User Resource Translation Module 
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The user resource translation module 1013 is responsible for 
translating user resources and the various user properties into a form 
that can be parsed and worked upon by the external rules engine. 

5 Pluggable Rules Engine 

The rules engine 1022 is an external, pluggable rules engine (in 
this embodiment of the invention) , such as the websphere™ personalization 
engine, that is used for dynamic rule parsing and execution. The engine's 
10 execution produces the set of portal resources that the user should see 

based on the business rules defined by the business user and the user 
properties of the current user. 



Portal Roles Based Personalization Engine 

The Portal roles based personalization engine 1008 is a roles based 
resource selection module that is used for extracting the list of portal 
resources a user is allowed to access and the list of portal resources the 
user is not allowed to access based on the user's organization membership. 



20 



The roles based engine 1008 first looks at the user's organization 
by accessing the roles database 1007. Once the user's organization has 
been determined, his role is assumed to BE the same as the role of that 
organization. After this the roles based personalization engine 1008 
25 extracts the list of resources that have been defined as accessible and 

inaccessible for this organization by the business user. Once this list 
has been determined IT is forwarded by this module to the portal 
aggregation engine's aggregated resource translation subsystem for further 
processing. 



Roles DB 

The Roles DB 1007 holds the organization data for the portal server. 

35 also the list of portal resources that members of an organization can and 

can not access based on their roles. 



Portal Aggregation Engine Aggregated Resource Translation Subsystem 



40 



This module 1004 is responsible for creating the master list of 
portal resources that the current user is allowed to see (this includes 
Harriets , pages, and page groups) based on the output of the rules and 
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rol.es based personalization engines. This module is also an adapter for 
the actual portal aggregation engine. Its job is to not only create this 
master list but also to translate it into a form that can then be accessed 
by the actual portal aggregation engine for creating the final web site 
5 for the end user . 

Part B: Operational Description 

B.l Portal and Web Application Integration Enabling Description 
0 B.l.l Overall Integration Structure & Flow Diagrams 

Figures 2, 3, and 4, depict respectively: web application 
integration with a portal; an integration structural diagram; and an 
integration flow diagram. 

Referring to Figure 2, when a backend web application is integrated 
with portal server, the backend web application 221 receives requests from 
the portal server 201 via portlets. The backend web application 221 sends 
:0 responses back to the portlet making the request. 

The response from the web application 221 is rendered via portlets 
of the portal server 201 to a user accessing the portlet. 

> 5 . With the implementation of the Portal Application HTTP client 209. 

multiple requests and responses to the backend web application are 
perceived by the back end web application as cohesive sessions. The Portal 
Application Http. client 209 is used to open Http communication connections 
to the backend web application 221. The backend web application requires 

handling and Single Sign On (SSO) capabilities. With the Portal 
Application HTTP client 209 in place, the portlets can effectively 
communicate with web application. All the portlets in a portlet 

^p p licat'i^ 



35 portlet application session object 211 of the back-end application 221, 

that means that Portal Application Http client 209 must be shared by all 
the portlets within the same portal application. 

To make such sharing possible we have determined that a unified 
session object that can be shared by all portlets in a given portal 
application is needed. To provide such an object the invention herein 
provides a Portlet Application Session object 208. The Portlet Application 
session object 208 is an object that is created by the commerce portlet 



40 
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application. The portlet application session object 208 is accessible by 
all portlets in a given portlet application (such as portlets 204, 205, 
206 in portlet application 1, 207) . Without the portlet application 
session object, 208, multiple portlets in a given portal application will 
5 all have independent user sessions and will not be able to share session 

related information. 



The Portlet Application Http client 209 is stored in the Portlet 
Application Session 208, making it possible to share it among portlets in 
10 the same portlet application. Without this portlet application session 

object it would not be possible for the portlets to communicate with a 
single web application session on the backend. 

All the data that is stored in the Portal Application Session object 

15 208 rep resent s Port al Application Session context and exists per user per 

portal application. 



Since the Portlet Application http client 209 holds all session 
information for the back-end web application 221, it is used as a base for 
20 the Session Relay mechanism 320 depicted in fig. 3. 

Session relaying allows session information to be relayed that is 
specific to the whole portal server 201 (such as language information, 
user agent information, etc) to the session information of the back-end 
25 web application 221. That means that the back-end web application 221 is 

able to deliver the data representation that conforms to all the 
requirements contained in the original request sent to the portal server 
by a user. 



30 For example, if the user accesses the portal using a WAP (wireless 

set to ^French" then The original http request to the portal server 201 
will have ITS language parameter set to ^French" and user-agent field of 

, - i .■ -t^M^e^ 

35 information to the web-application 221 and the web application returns a 

response in French that is suitable for display on the user's mobile 
device in French. If the Session Relaying were absent the web- application 
would return the information in the default- language (for example English) 
suited for the default device (for example an Internet Browser) . In that 

40 case the user would not be able to see the retrieved data as it would be' 

incompatible with the user's mobile device. 
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Reference will be made to elements in the structural diagram Figure 
3 while process steps of Figure 4 will be indicated by enumarated steps. 

Step 401, the user interacts with portlets on a web portal, for 
5 instance by using a computer mouse to click on a link or object displayed 

in a portlet on the user's web browser. Each portlet has its own portlet 
session 310 (portlet session is a piece of prior art) . As part of the 
user interaction, a remote request 306 is being made to be backend web 
application 307. 

0 

2. Step 403, in order to pass all the parameters in the portlet session 
correctly to the backend web application each portlet request's parameter 
list is saved in the Portlet Request Parameter Map (#8) 308. These 
parameters are passed to the remote back end request. 



3. Step 404, the commerce portlet uses a http client key 301 to 
determine if there is already an existing Portlet Application Session 
Object 208 and Portlet Application Http Client 303 by accessing portlet 
application data store #4, 302. step 405, If one is not found, a new one 
will be created for all the portlets within the same portlet application. 
(Step 407, If one is found, the existing one will be used instead.) 

4. Step 406, each user credential from the original portlet session is 
saved in the cookie table 305. 

5. Step 408, the user credentials from the cookie table 305 and the 
parameters previously saved in the portlet request parameter map 308 are 
used to construct a new http request to the backend web application. 

7. Step 410, the remote web application 307 returns a response to the 
call for the portlet to display. 



35 B.2 Dynamic Context Synchronization of Portlets 

B.2.1 Development Time Description 

Referring to Figure 5 which depicts a structural diagram of portal 
integration with a backend web application, it may be seen that a portal 
40 developer can make use of the Dynamic Context Portlet Grouping Tool 501 to 

create each new Dynamic Group Definition Instance 504 . This instance is a 
grouping of associate portlets and defines which portlets are slaves and 
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which portlet is the master of those slaves. The required elements of the 
Dynamic Group Definition ARE specified in the Dynamic Context Group 
Definition Template 503 . 

5 User uses the same tool 501 to update an existing Dynamic Context 

Group Definition. 

After the user has provided the latest dynamic context group 
definition, the Dynamic Context Portlet Grouping Tool 501 updates the 
0 appropriate portlet application deployment descriptors 502 to reflect the 

relationships defined in the group. 

Referring to Figure 6, a flow chart representing portal integration 
the steps of the above process may be more clearly visualized: 

iihen a user wants" to create (608) "or "update (609 )" a dynamic context 
group, the user can employ the grouping tool 501 (Fig. 5) . 

601, the dynamic context grouping tool prompts for user input based 
:0 on what is specified in the dynamic context group definition template 503, 

or in the case of updating the dynamic context grouping tool reads in an 
existing dynamic context group instance, validating it with the definition 
template 503 . 

> 5 603, the user specifies the required information to define or update 

a dynamic context group. 

605, the dynamic context group instance 504 is generated. 

in 606, the de plo yment descriptor of all related portlets are updated. 

Dynamic Context Grouping 



• :-l is comprised of master portlet 704, slave portlet 705, and slave 
pert-let: 707. 

Group 703 is comprised of master portlet 705, slave portlet 706, and 
slave portlet 707. 

r.ynamic group 702 is comprised of master portlet 704 and slave 

riQr.uIcL 708. 
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If the data that is represented by portlets in a Portlet Application 
is synchronized at the back-end application level, then the portlets 
deliver a coordinated view of the data just by retrieving that data from 
the web application. However, not all portlet interactions result in the 
5 changes at the backend web application. Dynamic context serves as the 

synchronization *at the glass'. It is most effective when a change in 
context requires a different query. For example, selecting a different 
account from the account list requires displaying of invoice information 
being refreshed with the account selected. 

0 

In prior art systems Portlets were normally independent of each 
another. This invention provides method and apparatus to map the relations 
of portlets with each other and articulate their dependency on each other 
at portlet application deployment and configuration time. The portlets 

The dependency relationships among portlets can be defined in a 
Dynamic Context Relationship Template 503 in which the master and slave 
relationships are defined. 

iO 

The Dynamic Context Relationship Template 503 is preferably encoded 
as an XML data representation that defines the following: 

the subset of portlets that constitute a dynamic context group 
>5 - the master portlet of a dynamic context group 

the slave ( s ) portlet of this dynamic context group 
the slave action that the slave (s) have to perform upon 
context state changes 

the context that all constituents of this dynamic context 
<DynamicContextGroup> 

bm ■ ■ iQ^rmai^o ■■■■ 1 1 ■ ■ 



3 5 </DynamicCont extGroupName> 

<DynamicContextMasterPortlet> 

Order I terns 
< / Dynami cCon t extMas t er Por 1 1 et > 
<Dynami cC ont ext > i t emName 
40 </ Dynami cC ont ext > 

<DynamicContextSlavePortlet> 

<DynamicContextSlavePortletJSrame>UPSTracking 
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</DynaitdcContextSlavePortletName> 
<SlavePortletAction> 

http : //inventorvserv er , com/ inStock/ 

</SlavePortletAction> 
</DynamicContextSlavePortlet> 
< / Dynami cCont ext Gr oup> 



<Dynami cC on t ext Gr oup> 

<Dynami cCon t extGr oupName> S t ocklnven t oryPor 1 1 etGroup 
3 < /DynamicCont extGr oupName> 

<Dynaitii cC on t extMas t er Por 1 1 e t > 

InStocklnventory 
</DynairdcContextMasterPortlet> 
<Dynami cCon t ext > i t emSKUnumber 

<Dynami cC on t ext S 1 aveP or 1 1 e t > 

<DynamicContextSlavePortletName>OrderedItems 
</DynamicContextSlavePortletName> 
<SlavePortletAction> 
0 ht tp : / /myserver . com/ lastOrdered/ 

</SlavePortletAction> 
</DynamicContextSlavePortlet> 
< /Dynami cContextGroup> 

5 The dynamic context group Definition Instances note: one dynamic 

context group definition is one instance. However, multiple dynamic 
context group definitions can be consolidated into one file to define 
multiple instances above defines two portlet sets in a portlet application 
consisting of 3 portlets. 

In the first dynamic context group, the dynamic context shared 
between the portlets is itemName, the portlet named Orderedl terns serves as 
Dynamic context Master portlet and portlets UPSTracking and 



In the second dynamic context group, the dynamic context shared 
between the portlets is itemSkuNumber, the portlet named InStocklnventory 
serves as Dynamic context Master portlet and portlet Orderedltems and 
swerves as the Dynamic context Slave portlets. 

Each Dynamic context Master portlet observes a user HTTP request and 
looks for the dynamic context. If the dynamic context is found in the 
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request, the dynamic context portlet sends a dynamic context (which is the 
name and value pair parameter in the http request) to the Slave port lets. 

For example if Orderedltems portlet receives an HTTP request with 
5 attribute itemName set to *PentiumXV* it sends the dynamic context to the 

portlets UPSTracking and InStocklnventory notifying them that context 
itemName with value *PentiumIV was now set in the dynamic context. 



Each Dynamic context Slave portlet listens to the master's 
.0 notification to all slave portlets of the same dynamic context group. Upon 

receiving the master's notification, the corresponding slave action is 
invoked by adding the dynamic context to the action URL as defined in the 
dynamic context group definition instance under attribute 
* SlavePortletAction' . 

For example if inStocklnventory portlet receives the dynamic context 
from Orderltems portlet with dynamic context type ^itemName'' and value 
*PentiumIV" it will retrieve the data from the 

Iittp : //inventorvserver . com/inStock/iteinNaine=PentiumIV url. 

10 

Coding for an example of a Dynamic Context Group Definition Template 
follows : 

<xsd: schema 

xmlns:xsd== n http: //www.w3 .org/2001/XMriSchema M 
IS xmlns : cep= 



n http : / /www . ibm . com/ WebsphereCommer ceEnabledPortal /DynamicContex 
tGroupDef initionSchema ,, > 

documentation xml : lang= 0 en n > 

Schema for Websphere Commerce Enabled Portal Dynamic Context 
Group Definition 

= ■ ■ m-= : — ~ = - == 

35 <documentation> 

</annotation> 



< I— Dynamic Context Group Instance --> 
<xsd : element name= "DynamicC on text Group " 
40 type="DynamicContextGroupDef initionTemplate" , 

minOccurs= ° 1 " /> 
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<! — Dynamic Context Group Definition Template Schema _ 
<xsd : complexType name= " DynamicContextGroupDef ini t ionTemplat e n > 
<xsd : seguence> 
<xsd : element name= p Dynami cC on t ext Gr oupName ■ 
5 type= tt xsd: string" /> 

<xsd : element name= • DynamicContextMasterPortlet " 
type=" PortletName" /> 

<I - only one dynamic context per dynamic context group -> 
<xsd: element name= u Dynami cConteart ° type=" Con text Parameter" 
l0 maxOccur s= " 1 * / > 

<xsd : element name= " Dynami cContext SlavePort let ° 
type= "SI avePor 1 1 et 9 

minOccurs= "1V> 

</xsd:sequence> 

<xsd: complexType name = 0 SlavePort let " > 

<xsd : sequence> 
<xsd : element name= " Dynami cContext SlavePort let ■ 
2 0 type= ■ Port 1 e tName n / > 

<xsd:element name=" SlavePort letAct ion" type="xsd: string" /> 
<xsd: element name=" SlavePort lefcRef resnPriority" 
type="xsd: decimal" , 

minOccur s= * 0 " /> 

25 <!- master's context is in the slave action url if slave param 

map is absent — > 

<xsd : element name= " SlaveParamMapToContext • 
type= "ContextParameter * 

minOccurs=" 0 9 /> 

</xsd: complexType> 
<xsd:simpleType name= u Portl etName ■ > 



35 </xsd:simpleType> 

<!- name of the parameter in master's request url — > 

<xsd: simpleType name= "Con text Par ameter u > 
<xsd: string> 
40 </xsd:simpleType> 

</xsd:schema> 
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B.2.2 Run Time 

This section will best understood by referring to Figure 8: Portlet 
Application Initialization For Dynamic Context As Specified In The 
5 Definition Instance; and 

Figure 9: Dynamic Context Portlet Group Run Time Flow. 
There are two key component to handle Runtime aspects of the Dynamic 
Context : 

.0 1) DynamicContextActionListener (904) (Portlet Action Listener) - it 

listens for the dynamic context change in the Master portlet. Master 
portlet in every Dynamic Context Portlet Group has 
DynamicContextActionListener attached to it. 

2) DynamicContextMessageListener (906) (Portlet Message Listener) — 



of the group where specific Dynamic Context is defined. Every Slave 
portlet in the Dynamic Context Portlets Group has a 
DynamicContextMessageListener attached to it. 

>0 Step-by-step description of the run-time flow: 

At portlet initialization time (Fig 8: 801), all master portlets 
will add the defined dynamic context based on the portlet descriptor (802, 
805) to the master portlet 1 s action listener (806) . For all slave 
1 5 portlets; the dynamic context type; the action url; the parameter mapping 

and the refresh sequence, will be retrieved from the portlet descriptor 
(802, 809) and add to the slave's portlet message listener (810). 

1) The user interaction with the Dynamic Context Portlet Group 
Master portlet results in the change of the Dynamic Context (901) . 

action (902) . 

3) DynamicContextActionListener sets the name/value pair 
corresponding to the Dynamic Context in the requests object of the 



35 4) Master Portlet gets the value of the Dynamic Context and notifies 

all the slave portlets within the same dynamic portlet group about 
it (905) . 

5) DynamicContextMessageListener associated with the Slave portlet 
for the given Master receives the notification (the value of the 
40 dynamic context) (906) . 
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6) DynamicContextMessageListener sets the value of the 
DynamicContext in the portlet request object of the Slave portlet. 
(907) . 

7) The Slave portlet gets the value of the dynamic context (1008). 

8) The Slave Portlet modifies action defined for the given Slave 
Portlet if the mapping between context and some parameter was 
specified (1009) . 

9) If the mapping was not specified, the name/value pair of the 
dynamic context is added to the Slave's Portlet action. 

10) Slave Portlet performs the Action as defined in the dynamic 
context group instance definition (1011, 1012) . 



B,3 Rule Based Role Based Dynamic Aggregation 



Figure 10: Role Based Dynamic Aggregation Component Structure Map; Figure 
11: Rule Based Dynamic Aggregation Component Structure Map; and, Figure 
12: Rule Based Dynamic Aggregation Flow Chart. 

0 The role and rules based dynamic aggregation components for the 

portlet server are based around the rules and roles databases and the 
concept of content groups for each role and rule. 

The content groups for the rules are kept in the Rules DB component 
;5 1001 shown in Figure 10. Similarly the roles content groups are defined in 

the Roles DB component 1007 shown in Figure 10. Each content group 
consists of a set of portal server resources that a user who has been 
evaluated to fall under the purview of that particular role or rule should 
have access to. 

Another major component in this scheme is the PTSggame Rules EngXne 
1022. The . task of this engine is to read in the translated user properties 
and decide dynamically at runtime the set of users who qualify for 



;? ■r, 



-r-r^ies. 



Also this engine maps the set of these dynamic user groups to 
the set of content groups that have been defined in the roles and rules 

Preferably the Pluggable Rules Engine has a GUI to manage these tasks. 
The screen shot depicted in Figure 16 illustrates how we use the WebSphere 
n^^aijzation Server Engine to manage these tasks. 
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For example, Figure 16 illustrates how we define a dynamic group 
called "MaleTeen" and assigns all male users of ages between 16-19 to this 
group. 

As shown in Figure 17, which depicts all users who are dynamically 
evaluated to be male teenagers based on their properties will now have the 
^maleteenaction" command executed for them which would instruct the 
dynamic rules and roles based portal aggregation engine 1022 to select 
content resource for the male teen group from the Roles DB 1007. 



At development time it is the task of a business manager to assign a 
set of portal resources such as: pages, portlets etc. to a specific 
content group in the Roles and Rules DB. This is currently done by using 
SQL scripts that directly load the Rules and Roles DB. 



B.3.1 Rule Based Role Based Dynamics Aggregation Run Time Enabling 
Description 

At runtime the first command to execute for a portal user is the 
tO wrapper command for the rules based engine. This command is actually a 

proxy that starts the evaluation of user's properties by the actual 
pluggable rules engine. 

In the next step the rules engine reads in the user's properties 
>5- from his stored profile, by utilizing the user resource translation module 

to translate them into a form that can be understood by it. 

Figure 18 illustrates the creation of a new action called 
^MaleTeenAction" which selects all the portal resources that have been 



Figure 17 illustrates creation of a dynamic aggregation module 
command instructing the aggregation module to select the contents of the 



35 previously created rule for classifying *MaleTeens" based on dynamic user 

properties . 

Figure 17 illustrates how a given business rule (e.g. business rule 
in defining what constitutes a maleteen group) takes effect (e.g. 
40 maleTeenAction) in determining what content to aggregate for a given user, 

with a certain user properties, falls under such classification. 
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After reading in the user properties the pluggable rules engine 
evaluates the dynamic group membership of this user based on the rules 
defined for the various dynamic groups as shown in Figure 18. 

5 Once the set of dynamic groups for this user has been ascertained 

the rules engine selects the appropriate portal content for this user by 
executing the content select ion actions defined for this dynamic group as 
shown in Figure 18. These actions upon execution return the set of portal 
resources from the content groups defined for them in the Rules DB. 

0 

The next execution step is the evaluation of the roles assigned to 
this user by the roles engine. The roles engine uses the organization 
membership (extracted from the user profile properties) to extract the set 
of content resources for this user's role from the Roles DB. These 

portal resources created in the previous set. 

This list is then forwarded to the dynamic Portal Aggregation Engine 
for execution. The dynamic portal aggregation engine then selects the 
;0 portal resources identified by this list to set up the default portal view 

for this current user. 



Summary 

> 5 i. Common Backend Web Application Integration implementation 

1 With the Portlet Application Http Client and Portlet Application 
Session, it is now possible to have a common backend web application • 
integration model. This can be used to enable multiple portlets within the 

backend . 

This implementation makes it possible to: 



have ft lgive"^^ 



browsers, and without requiring multiple prompts for user id and password 
to access the same backend web application; 

ii. make multiple requests and receive responses to/from the backend 
application with session management. 



Simple Common system leading to simple tooling 
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The instant implementation, provides an easy and quick method to 
integrate portlet applications with an existing web application operating 
on a backend server; with merely requiring the specification of the url of 
the pertinent backend web application in the deployment descriptor of the 
portlet application. With this, it becomes possible to build tooling to 
take care of the commonality tasks of the integration. 

3 . Portlets Within The Portlet Application Share Common Session and 
Session Data 

The implementation of a portlet application session object makes it 
possible for portlets of the same portlet application to share common data 
among themselves that are unique within a portlet application, while at 
the same time being different from that of the original http session of 

^^^^^^^^^ ^^ j^^^ ^^^^^^^5^^^^^^^^ 
portlets within the same portlet application. 

4. . Portal Session and Back End Session Sharing Common Session Data 

The session relay implementation makes possible the sharing of 
common session data between a portal server and its backend web 
application. This enables the backend web application to receive 
information from the portal server, enabling business logic of the web 
application to exploit this information passed from the portal server. 

For example: if the current portlet state is to display the 
maximized view of the portlet, the backend web application can receive 
this piece of information and take advantage of this by sending back 
detailed business information, in contrast to the normal view of a 

=Lckend web application would just send a 



summary version of the information. 

5. Cohesive Back End Web Application Session Distinct From The Portal 
"Se w e r 1 TO-fi WTW BlB g a^lOui^U^ ^^^^^^^.^ftglCT 
object, portlet http client, and the session relay mechanism A back end 
web application can now preserve its own session distinct from that of the 
portal server, but still share the same cookie with that of the portal 
server. The backend web application can now operate independently and 
correctly, perceiving portlet requests from various portlets in a portal 
as one virtual client, enabling a cohesive session with the backend web 
application. 
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6. Single Sign On Across Portal Server and Back End Web Application 

The session relay embodiment provides single sign-on capability such 
that the user, once logged on to a portal server, is not required to 
5 resubmit user credentials to log on to the pertinent back end web 

application. This is enabled by means of a cookie table with one to one 
mapping between the http session to the portal and the http session from 
the portlet http client to the backend web application. 

10 7. Back End Web Application Behavior Synchronized With That of the 

Portal Server 

The session relay embodiment enables enabling seamless integration 
by synchronizing the behavior of a backend web application by relaying the 

15,. , ^session-jjafoi^ _ 

web application. 

The following are some examples: 

20 The language and locale setting in a portal server can now be passed 

to its backend web application so that the backend application can now 
compose a response message based on the locale + language setting of the 
portal server. 

25 Another example is that session expiry information from the portal 

server can now be passed to the backend web application session so that 
the backend web application session can now be timed out at the same time 
that the portal session times out. The backend web application can now be 
responsive to the portal state and events as relayed from the portal 



8 . Synchronized Content Within The Same Portal Page 



35 Dynamic Context Portlet Grouping allows collaboration among portlets 

within the same dynamic context group to achieve business process and 
information integration and synchronization. 



40 



Each portlet is allowed to participate in multiple Dynamic Context 
Groups. This provides a very open and simple programming model for portal 
administrator to group portlets into dynamic context portlet groups. 
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The simple structure of Dynamic Context definition enables simple 
tooling to be built for automatic generation of Dynamic Context Master and 
Slave portlets for each grouping. 

5 Dynamic Context Definition implementation, Dynamic Context Group, 

master portlet and slave port let implementation (including the slave 
tasks, slave context map) assist in providing advantages. 

9 . Ability To Define Refresh Sequence of Portlets 

0 

The transaction manager provides the capability of defining a 
refresh sequence of portlets for the first time. The ability to define 
refresh sequence of portlets enables proper implementation of sequential 
business logic using the portal / portlet architecture. The transaction 

advantages of the invention. 



10. Rule Based and Role Based Aggregation 



,0 



!5 



Fine level portal personalization can only be achieved at present by 
dynamic aggregation. This is distinctly different from the prior art 
implementation of regular web applications in which there is no formal 
concept of portlets, pages or page groups. Fine level personalization will 
become more and more important as the portal market takes off and user 
requirements for fine level campaign targeting etc. come in. 

The ? described embodiments provide a number of advantages which are 
listed below: 



35 



much finer grained than. Portlet administration facilities proviolecL^by 
portal server today. The portlet administration facilities available today 
is by nature manual configuration. Once configured, it is static and does 

to render portal resources based on rule. 



40 



2. Since the portal aggregation module is a dynamic entity, tying of 
rules and roles engines directly to it lets us achieve real-time dynamic 
aggregation capabilities without any human intervention. 

3 . Personalization of coarse grained portal resources such as pages and 
page groups lets us perform dynamic layout. 
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4. Much more effective campaigns, contracts etc. can be set up. This is 
of significant importance to both e-Commerce retail and B2B organizations. 

5 . A much higher degree of personalization than regular content 
personalization is achieved. For example, entire sections of a webpage can 
be disabled based on rules. This can't be done by regular personalization. 
Further, dynamic aggregation doesn't apply to the domain of regular 
personalization which is content, not resource related. 
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